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REMARKS 

The FINAL Office Action issued April 28, 2009, has been carefully considered and these 
remarks are responsive thereto. Minor amendments to claims 3, 4, 22, 23 and 24 have been 
made to place the claims in better form for appeal. With respect to claims 3 and 4, ActiveX has 
been corrected to conform to its use in the specification and other claims. With respect to claims 
22 and 23, "redirected client" has been corrected to read "redirect client" to conform to FIG. 2 
and "redirect client 335" as used in the specification. Claim 24 has been amended to correct an 
antecedent basis error with respect to "the client terminal." None of these amendments are 
believed to be substantive in nature and entry for purposes of appeal is respectfully requested. 

The Examiner has rejected the pending set of claims 1-31 under 35 U.S.C. 102(e) as 
being anticipated by Luo, U.S. Pub. No. 2003/0169713 (hereinafter Luo). No other reference has 
been applied in the rejection nor has an issue of obviousness been raised. 

The proper test for "anticipation" is set forth in NetMoneyin, Inc. v. Verisign, Inc. et al, 

decided less than eight months ago, October 20, 2008, (545 F. 3 rd 1359, at 1369): 

Section 102(a) provides that an issued patent is invalid if "the invention [therein] 
was . . . described in a printed publication . . . before the invention thereof by the 
applicant." Section 102 embodies the concept of novelty — if a device or process 
has been previously invented (and disclosed to the public), then it is not new, and 
therefore the claimed invention is "anticipated" by the prior invention. As we 
have stated numerous times (language on which Verisign relies), in order to 
demonstrate anticipation, the proponent must show "that the four corners of a 
single prior art document describe every element of the claimed invention" 
(citations omitted). This statement embodies the requirement in section 102 that 
the anticipating invention be "described in a printed publication," and is, of 
course, unimpeachable. But it does not tell the whole story. Because the 
hallmark of anticipation is prior invention, the prior art reference - in order to 
anticipate under 35 U.S.C. 102 - must not only disclose all elements of the 
claim within the four corners of the document, but also disclose those 
elements "arranged as in the claim," (citation omitted) (our emphasis added). 

The Examiner Has Failed to Demonstrate Anticipation of Claims 1-31 

The undersigned counsel must respectfully traverse the Examiner's anticipation rejection 
and sets forth below a discussion of each independent claim and dependent claim series in the 
order presented by the Examiner and remarks as to why the claim (or claims) is not anticipated 
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by Luo and, consequently, is patentable over Luo. The below remarks mirror the DETAILED 
ACTION, beginning at Page 2, 4. 
Claims 1 and 5 

Independent claims 1 and 5 include the feature of "redirecting the access request to a 
local web server via a packet traffic filter for filtering packet traffic." Claim 1 is a method claim 
and claim 5 is in means plus function format. Luo does not teach or suggest this feature for at 
least the following reasons. 

Primarily, nowhere in Luo is there a teaching or suggestion about redirecting via a packet 
traffic filter for filtering packet traffic. The Examiner refers to a "web-based authentication 
server" (Luo at [0018]). But a web-based authentication server per Luo does not encompass a 
packet traffic filter according to claim 1. In Luo, per [0018], it is new users that can refer the 
Web-based authentication server to other authentication servers. Further in Luo, per [0039], the 
Web authentication server again does not itself perform any redirection. Rather, it replies with a 
redirect URL to a secure port of the same server - so that the user's browser is redirected ~ not 
with a redirection as per claim 1 . 

Further, in his Response to Arguments Page 10, 33., the Examiner points to Luo [0023] 
and states as follows: "Luo discloses that certain packets are allowed to pass through while 
others are filtered based on state information." This interpretation fails on several counts. 
Firstly, Luo [0023] fails to disclose or suggest what happens to an access request, secondly, that 
the access request is redirected, thirdly, that when the access request is redirected, the access 
request is redirected to a local web server and, fourthly, that the redirecting of the access request 
is via a packet traffic filter for filtering packet traffic. 

Luo [0023] clearly indicates that whatever function is performed regarding passing and 
blocking "frames" is performed as a condition of the mobile host's routing state. There is no 
discussion of what happens to an access request. Luo uses the term "MH associates with MAP" 
- mobile host associates with mobile access point at 200 of Fig. 2. Luo states: "The mobile 
host's routing state is set to 'normal,' 'limited' or 'blocked.' The 'normal' state means that the 
mobile host has been authenticated ... the access point will relay all frames that are 
communicated to or from the mobile host. A 'limited' state means ... the access point should 
block all frames except those carrying IP configuration packets . . . between the mobile host and 
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the WLAN, DNS (domain name server) packets between the mobile host and the conditional 
DNS server, and HTTP packets between the mobile host and the web-based authentication 
server." "A 'blocked' state means ... the access point will block all frames sent to and from the 
mobile host." 

A possible interpretation of Luo is that in a "limited" state some frames carrying IP 
configuration packets, domain name server packets and HTTP packets are passed. But, if for the 
purposes of discussion this "limited" state involves a packet filter as broadly interpreted, these 
types of packets are not an "access request" as recited that is redirected to a local web server. 

Accordingly, Luo, at least, does not teach or suggest the feature of "redirecting the access 
request to a local web server via a packet traffic filter for filtering packet traffic" per claim 1 or 
the means of claim 5. 

Yet further, there are additional features of claim 1 (5) also not taught or suggested by 

Luo. 

Claims 1 and 5 include the feature of "activating, in response to the client terminal access 
information received from the client terminal, a module that reconfigures the client terminal for 
authentication using appropriate parameters associated with a configuration arrangement selected 
by the user." Luo does not teach or suggest this feature for at least the following reasons. 

For example, Luo Fig. 2 208 states "MH runs DHCP to receive IP address and network 
configuration parameters from MAP." It is not until block 238 that "Web auth. Server sends 
Java applet to MH." Consequently, since it appears that the Examiner is equating the Luo Java 
applet to the recited module, the Examiner is precluded from assuming that Luo performs 
"activating, in response to the client terminal access information received from the client 
terminal, a module that reconfigures the client terminal for authentication using appropriate 
parameters associated with a configuration arrangement selected by the user" where the sending 
of a Java applet at 238 is the last block of the Luo process Fig. 2. See Luo at paragraphs [0045] 
and [0046]: 

"...After the Java applet is downloaded at 238, it grants some networking 
privileges so that it can listen to a specific UDP port . . . .The mobile host can now 
use the assigned IP address during the entire session as long as it is under the 
coverage of the WLAN . The user should keep this small browser window always 
open. The Java applet runs in this small browser window and authenticates the 



11 



Customer No. 24498 Atty. Docket No. PU030084 

Appln. Serial No. 10/549,407 
Response to Final OA dtd 4/28/2009 

user to the WLAN as the user moves from one MAP to another, (emphasis 
added). 

In summary, Luo has no "module that reconfigures" as per claims 1 and 5, let alone, 
"using appropriate parameters associated with a configuration arrangement selected by a user" as 
recited. Luo's Java applet is not activated in response to the client terminal access information 
received from the client terminal in accord with Applicant's invention; it is downloaded at the 
end of the process and operates in a window that must be forever open. 

For at least the reasons above, Luo does not disclose every feature of claims 1 and 5 and, 
therefore, the Examiner cannot support a prima facie case of anticipation. Consequently, claims 
1 and 5 are patentable over Luo. Reconsideration of the anticipation rejection of claims 1 and 5 
is respectfully requested. 

Claims 2 and 6 

Claims 2 and 6, directly or indirectly, depend on claims 1 and 5, respectively, and 
incorporate every feature thereof. Therefore, claims 2 and 6 are patentable over Luo by virtue of 
their dependencies as well as based on their own merits. In particular, claims 2 and 6 include the 
feature of an IEEE 802. 1 1 compliant network and terminal. Luo does not teach or suggest this 
feature. It is respectfully submitted that Luo cannot anticipate use of a standard whose pertinent 
features were yet to be determined and/or incorporated in that standard at the time of Luo's 
filing. Claims 2 and 6 refer to IEEE 802.11 at the time of the filing of the present application, 
not the time of Luo's filing of the Luo patent application (2001). Luo admits at [0007], "To 
address the security flaws associated with WEP, the IEEE 802. lx standard has been introduced 
and the IEEE 802.11i standard is currently under development.'' (our emphasis added). 
Reconsideration is respectfully requested. 

Claim 3 

Claim 3, directly or indirectly, depends on claim 1 and incorporates every feature thereof. 
Therefore, claim 3 is patentable over Luo by virtue of its dependency from claim 1 as well as 
based on its own merits. Additionally, however, claim 3 includes the feature wherein activating 
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comprises "activating an ActiveX control/plug-in installed on the client terminal." Luo does not 
teach or suggest this feature. Luo refers to a Java applet at the end of the Luo process. 

At Page 3, the Examiner contends that Luo paragraphs [0018] and [0045] anticipate the 
above-identified feature. Yet, Luo is completely silent about an ActiveX control/plug-in in 
accord with Applicant's invention. The Examiner appears to be equating ActiveX perfectly with 
a Java applet, despite their completely different uses. Luo's Java applet is downloaded at step 
236 in an always-open small browser window which runs the applet; see Luo at [0046]. This 
Java applet is not a "module that reconfigures the client terminal for authentication using 
appropriate parameters associated with a configuration arrangement selected by a user." 
according to claims 1 and 3. The Java applet performs no reconfiguration. Consequently, for at 
least the reasons above, reconsideration is respectfully requested. 

Claim 4 

Claim 4, directly or indirectly, depends on claim 1 and incorporates every feature thereof. 
Therefore, claim 4 is patentable over Luo by virtue of its dependency from claim 1 as well as 
based on its own merits. In particular, for similar reasons that claim 3 is not anticipated, neither 
is claim 4 because claim 4 calls for an ActiveX control/plug-in. Consequently, reconsideration is 
respectfully requested. 

Claim 7 

Like claims 1 and 5, independent claim 7 includes the feature of "filtering traffic 
associated with a request from the client terminal for access to the wireless network, at a packet 
traffic filter for filtering packet traffic; redirecting the access request to a designated web server, 
via said packet traffic filter for filtering packet traffic." Luo does not teach or suggest these 
features individually or "arranged as in the claim," Verisign, Id. Accordingly, for at least the 
similar reasons that claim 1 is not anticipated, neither is claim 7. 

Moreover, claim 7 further includes the features of "filtering traffic associated with a 
request from the client terminal for access to the wireless network, at a packet traffic filter for 
filtering packet traffic; redirecting the access request to a designated web server, via said packet 
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traffic filter for filtering packet traffic" in particular sequence. Luo does not teach or suggest 
these features in sequence. 

Nowhere in Luo is found "issuing a provider list web page and a request from the 
designated web server to the client terminal for provider selection information to establish an 
authorized communication." Nowhere in Luo is a provider list web page referenced, let alone a 
request for provider selection information in accord with claim 7. The paragraphs cited by the 
Examiner ([0018], [0037]-[0038]) do not appear to provide any sort of support for the 
Examiner's contention of anticipation. Paragraph [0018] nowhere refers to a list of providers. 
While it does appear to allow "new users to refer the Web-based authentication server to other 
authentication servers where they have accounts," this is not the same as issuing a provider list 
web page in accord with claim 7. Paragraphs [0037]-[0038] appear to contain no references 
whatsoever to service providers, let alone a list of service providers. 

For at least the reasons above, Luo does not disclose every feature of claim 7 and, 
therefore, the Examiner cannot support a prima facie case of anticipation. Consequently, 
independent claim 7 is patentable over Luo. Reconsideration of the anticipation rejection of 
claim 7 is respectfully requested. 

Claim 8 

Claim 8, directly or indirectly, depends on claim 7 and incorporates every feature thereof. 
Therefore, claim 8 is patentable over Luo by virtue of its dependency from claim 7 as well as 
based on its own merits. In particular, at Page 4, the Examiner rejects claim 8 by referring to 
Luo [0018] for the feature wherein "the wireless network is an IEEE 802.11 compliant wireless 
local area network and the client terminal is an IEEE 802.1.x compliant client terminal." For at 
least the similar reasons that claim 2 is not anticipated, neither is claim 8. The claim refers to 
IEEE 802.11 at the time of the filing of the present application, 2005, not at the time of Luo's 
filing his application, 2001. Reconsideration is respectfully requested. 

Claim 9 

Claim 9, directly or indirectly, depends on claim 7 and incorporates every feature thereof. 
Therefore, claim 9 is patentable over Luo by virtue of its dependency from claim 7 as well as 
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based on its own merits. In particular, the Examiner contends that a Luo "credential" [0043] 
somehow anticipates the feature of the "designated web server receiving from the client terminal 
said provider selection information for establishing said authorized communication." Luo, 
however, does not disclose this feature, for at least the reasons below. 

At Page 4, the Examiner contends that claim 9 includes the feature of "information 
required to establish an authorized connection." But this feature is not part of claim 9. The 
designated web server according to claim 9 receives "provider selection information" — not 
"information required to establish an authorized connection" per the Examiner. Because a 
"credential" per Luo does not teach or suggest claim 9's feature of "provider selection 
information," claim 9 is allowable over Luo. Reconsideration is respectfully requested. 

Claim 10 

Claim 10, directly or indirectly, depends on claim 7 and incorporates every feature 
thereof. Therefore, claim 10 is patentable over Luo by virtue of its dependency from claim 7 as 
well as based on its own merits. In particular, claim 10 includes the feature of the "client 
terminal receiving information corresponding to parameters from the designated web server and 
including transmission rate information for establishing said authorized communication." Luo 
does not teach or suggest this feature for at least the following reasons. 

At the time of Luo, 2001, IEEE 802.1b, in effect at the time, used preset data rates in the 
basic service set. IEEE Std 802.1 lb-1999 (R2003), Part 11: Wireless LAN Medium Access 
Control (MAC) and Physical Layer (PHY) specifications: Higher-Speed Physical Layer 
Extension in the 2.4 GHz Band at Section 3.8. It was not until 2003, after the filing of Luo, that 
IEEE 802. lx evolved to permit much more flexibility in data rates, including choosing of 
transmission data rates. IEEE Std 802.1 lg tm -2003t, Part 11: Wireless LAN Medium Access 
Control (MAC) and Physical Layer (PHY) specifications Amendment 4: Further Higher Data 
Rate Extension in the 2.4 GHz Band at Section 10.4.4.2. Accordingly, Luo does not disclose the 
feature of transmission rate information according to claim 10. Reconsideration is respectfully 
requested. 

Claim 11 
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Claim 11, directly or indirectly, depends on claim 7 and incorporates every feature 
thereof. Therefore, claim 1 1 is patentable over Luo by virtue of its dependency from claim 7 as 
well as based on its own merits. Reconsideration is respectfully requested. 

Claim 12 

Claim 12, directly or indirectly, depends on claim 7 and incorporates every feature 
thereof. Therefore, claim 12 is patentable over Luo by virtue of its dependency from claim 7 as 
well as based on its own merits. In particular, claim 12 includes the feature of the client terminal 
receiving information corresponding to parameters from the designated web server including 
authentication method selection information for establishing said authorized communication. 
Luo does not teach or suggest this feature for at least the following reasons. 

At Page 5, the Examiner appears to contend that Luo's "positive acknowledgment page at 
228" [0044] anticipates the above-identified feature. But a positive acknowledgment page per 
Luo does not include authentication method selection in accord with claim 12. Fig. 2 of Luo 
describes a flow diagram of connection procedure for a mobile user to connect to a WLAN. 
Nowhere in this procedure is there a teaching or suggestion that authentication method 
information is exchanged between Luo's web authorization server and mobile host (MH). 
Because a positive acknowledgement page per Luo does include authentication method selection, 
claim 12 is allowable over Luo. For at least the reasons given above, reconsideration is 
respectfully requested. 

Claim 13 

Claim 13, directly or indirectly, depends on claim 7 and incorporates every feature 
thereof. Therefore, claim 13 is patentable over Luo by virtue of its dependency from claim 7 as 
well as based on its own merits. Reconsideration is respectfully requested. 

Claim 14 

Claim 14, directly or indirectly, depends on claim 7 and incorporates every feature 
thereof. Therefore, claim 14 is patentable over Luo by virtue of its dependency from claim 7 as 
well as based on its own merits. In particular, claim 14 includes the feature of "the client 
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terminal receiving information corresponding to parameters from the designated web server 
including access user terms and conditions of acceptance information for establishing said 
authorized communication" (our emphasis added). Luo does not teach or suggest this feature for 
at least the following reasons. 

At Page 5, the Examiner appears to contend that Luo's authentication page [0018], [0043] 
anticipates the above-identified feature. But nowhere in Luo is there a teaching or suggestion 
regarding access user terms and conditions of acceptance as part of a Luo authentication page. 
In Luo, a MH is sent an authorization page, from which the user responds with an authorization 
credential — not access user terms and conditions of acceptance in accord with claim 14. Luo, 
Fig. 2 steps 222 and 224. Accordingly, claim 14 is allowable over Luo. For at least the reasons 
given above, reconsideration is respectfully requested. 

Claim 15 

Claim 15, directly or indirectly, depends on claim 7 and incorporates every feature 
thereof. Therefore, claim 15 is patentable over Luo by virtue of its dependency from claim 7 as 
well as based on its own merits. In particular, claim 15 includes the feature of the client terminal 
"communicating to the designated web server access rate information for establishing said 
authorized communication." For at least similar reasons as discussed regarding claim 10, above, 
Luo does not teach or suggest this feature. Reconsideration is respectfully requested. 

Claim 16 

Claim 16, directly or indirectly, depends on claim 7 and incorporates every feature 
thereof. Therefore, claim 16 is patentable over Luo by virtue of its dependency from claim 7 as 
well as based on its own merits. Reconsideration is respectfully requested. 

Claim 17 

Claim 17, directly or indirectly, depends on claim 12 and incorporates every feature 
thereof. Therefore, claim 17 is patentable over Luo by virtue of its dependency from claim 12 as 
well as based on its own merits. Reconsideration is respectfully requested. 
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Claim 18 

Claim 18, directly or indirectly, depends on claim 14 and incorporates every feature 
thereof. Therefore, claim 18 is patentable over Luo by virtue of its dependency from claim 14 as 
well as based on its own merits. Reconsideration is respectfully requested. 

Claim 19 

Claim 19, directly or indirectly, depends on claim 9 and incorporates every feature 
thereof. Therefore, claim 19 is patentable over Luo by virtue of its dependency from claim 9 as 
well as based on its own merits. In particular, claim 19 includes the feature "authentication is 
browser based and related to said provider list web page and the method further comprising 
invoking an ActiveX control to reconfigure the client terminal." Nowhere in Luo is there a 
teaching or suggestion of a provider list web page, let alone authentication that is related to a 
provider list page. The failure of Luo to teach or suggest "invoking an ActiveX control to 
reconfigure the client terminal," when Luo has no reconfiguration or ActiveX control, has 
already been discussed. Reconsideration is respectfully requested. 

Claim 20 

Claim 20, directly or indirectly, depends on claim 8 and incorporates every feature 
thereof. Therefore, claim 20 is patentable over Luo by virtue of its dependency from claim 8 as 
well as based on its own merits. Reconsideration is respectfully requested. 

Claim 21 

Independent claim 21 includes features that have been discussed above. In particular, 
claim 21 includes the feature of a mobile terminal comprising, in part, means for forwarding a 
web access request via a packet traffic filter for filtering packet traffic. For similar reasons as 
discussed in connection with claims 1 and 5, Luo does not teach or suggest this feature. Claim 
21 additionally includes the feature of a means for receiving a provider list web page. For 
similar reasons as discussed in connection with claim 7, Luo does not teach or suggest this 
feature. For at least these reasons, independent claim 21 is patentable over Luo, and 
reconsideration is respectfully requested. 
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Claim 21 is rejected as anticipated by Luo with reference to Luo [0018] for EAP for 
"means for receiving an extended authentication protocol request identification message packet." 
At [0013], Luo discusses "Lightweight Extensible Authentication Protocol (LEAP)" and Luo 
states: "the user must create an account using an out-of-band method, even if he or she is within 
the coverage of the LAN" as a problem. Luo does not describe a specific solution to the problem 
aside from reference to alternative protocols. 

In [0018], Luo discusses EAP-TLS or EAP-TTLS-PAP as potential authentication 
methods and specifically describes: "The Web-based authentication server employs a Web page 
for initial authentication and a Java applet (or an equivalent client- side program delivered by the 
Web page and installed by the user. Hereafter it is assumed to be a Java Applet for the sake of 
simplicity, although a binary code is preferred) for consequent authentications. In the Web page, 
registered users can manually, or configure their Web browsers to automatically, submit their 
authentication credentials. . ." Luo [0018] does not provide a discussion of "means for receiving 
an extended authentication protocol request identification packet," as supported by FIG. 2. The 
Examiner is respectfully requested to cite to support for his rejection as [0018] appears to be 
silent as to the "means for receiving . . ." Luo discusses EAP conditionally as one or another of 
EAP-TLS or EAP-TTLS-PAP. The Examiner is requested to cite to and provide a copy of a 
document discussing EAP in the context of claim 21 on which the Examiner relies if such a 
document further supports the Examiner's position. 

The Examiner cites to Luo [0018] also for "forwarding an extended authentication 
protocol response identity message packet." The manual or automatic submission of credentials 
described by Luo is not described as "an extended authentication protocol response identity 
message packet." Again, the Examiner is respectfully requested to cite support for his rejection 
based on Luo or another reference. 

The Examiner now cites to Luo [0023] for "means for receiving an extended 
authentication protocol failure message packet." It is respectfully submitted that nowhere in 
[0023] is failure mentioned, let alone, EAP failure. The Examiner appears to rely on "limited" or 
"blocked" states. Yet, Luo can only rectify a "limited" state which may or may not be the same 
as a "mobile terminal" comprising "means for receiving an extended authentication protocol 
failure packet." The depicted Mobile State Table 118 is a part of the MAP 102, not MH 106 
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which is analogous to a "mobile terminal" as recited. And so again, the Examiner is respectfully 
requested to cite support for his rejection based on Luo or another reference describing EAP 
message delivery to a MH 106. Nowhere in Luo's flowchart Figure 2 is such a receiving step 
suggested or described. 

The Examiner now relies on Luo [0037]-[0038] for user-to-network authentication. But 
these paragraphs refer to a DNS query such as www.att.com and receives an IP address for a 
Web authentication server in the WLAN. This is not "means for receiving a provider list web 
page" or "means for forwarding selected provider information." Luo [0018] hardly says 
anything about "new users can open accounts." Moreover, an ActiveX control/plug-in may be 
similar to but, as recited, is not structurally or functionally equivalent to a Luo Java applet. As 
claim 21 states: "an ActiveX control/plug-in from the designated web server to reconfigure said 
mobile terminal," this is not a Luo Java applet that is downloaded and must remain open and 
listening and "grants some networking privileges" to generate AUTHENTICATION 
RESPONSE messages after it "shares a high entropy secret" with the Web authentication server. 
Luo fails to teach "an ActiveX control/plug-in from the designated server to reconfigure said 
mobile terminal." Again, the Examiner is respectfully requested to cite support for his rejection 
based on Luo or another reference describing EAP and an ActiveX control message, not Luo's 
Java applet. 

Claim 22 

Claim 22 depends on claim 1 and incorporates every feature thereof. Therefore, claim 22 
is patentable over Luo by virtue of its dependency from claim 1 as well as based on its own 
merits. Reconsideration is respectfully requested. 

Claim 23 

Claim 22 depends on claim 5 and incorporates every feature thereof. Therefore, claim 23 
is patentable over Luo by virtue of its dependency from claim 5 as well as based on its own 
merits. Reconsideration is respectfully requested. 

Claim 24 
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Independent claim 24 includes the feature of an "alternative means for receiving a request 
for access to a communications network at said packet filter module responsive to said state 
failure." Luo does not teach or suggest these features. 

The Examiner at Page 8 contends the Luo routing table (paragraph [0023]) anticipates the 
above feature of claim 24. Applicants disagree. The "routing table" in Luo is not an alternative 
means for receiving a request for access. In Luo, the routing state table entries associate host IP 
and host MAC addresses with each address' particular routing state. So far as it can be 
ascertained, there is only one routing state table entry per mobile host and access point. 
Therefore, alternative means for access to a communications network according to claim 24 is 
not possible given the configuration of the routing table entries per Luo. Moreover, per the 
discussion in connection with claims 1 and 5, Luo does not teach a packet filter module in accord 
with Applicant's invention. 

Independent claim 24 further includes the feature of a "means for forwarding a web 
request redirect from said packet filter module ...following receipt of selected provider 
information." For similar reasons as discussed in connection with claim 7, Luo does not teach or 
suggest this feature. 

For at least the reasons above, Luo does not disclose every feature of claim 24 and, 
therefore, cannot support a prima facie case of anticipation. Consequently, independent claim 24 
is patentable over Luo. Reconsideration of the anticipation rejection of claim 24 is respectfully 
requested. 

Claim 25 

Claim 25 depends on claim 1 and incorporates every feature thereof. Therefore, claim 25 
is patentable over Luo by virtue of its dependency from claim 1 as well as based on its own 
merits. Reconsideration is respectfully requested. 

Claim 26 

Claim 26 depends on claim 5 and incorporates every feature thereof. Therefore, claim 26 
is patentable over Luo by virtue of its dependency from claim 5 as well as based on its own 
merits. Reconsideration is respectfully requested. 
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Claim 27 

Claim 27 depends on claim 7 and incorporates every feature thereof. Therefore, claim 27 
is patentable over Luo by virtue of its dependency from claim 7 as well as based on its own 
merits. Reconsideration is respectfully requested. 

Claim 28 

Claim 28 depends on claim 1 and incorporates every feature thereof. Therefore, claim 28 
is patentable over Luo by virtue of its dependency from claim 1 as well as based on its own 
merits. In particular, claim 28 includes the feature "wherein said information to establish client 
terminal access to the wireless network comprises provider selection information responsive to 
receipt of a provider list web page." For the reasons discussed above in connection with claim 7, 
Luo does not teach or suggest at least the "provider selection information responsive to receipt of 
a provider list web page" feature. For at least these reasons, reconsideration is respectfully 
requested. 

Claim 29 

Claim 29 depends on claim 5 and incorporates every feature thereof. Therefore, claim 29 
is patentable over Luo by virtue of its dependency from claim 5 as well as based on its own 
merits. In particular, claim 29 includes the feature "wherein said information to establish client 
terminal access to the wireless network comprises provider selection information responsive to 
receipt of a provider list web page." For the reasons discussed above in connection with claims 7 
and 28, Luo does not teach or suggest this feature. For at least these reasons, reconsideration is 
respectfully requested. 

Claim 30 

Claim 30, directly or indirectly, depends on claim 21 and incorporates every feature 
thereof. Therefore, claim 30 is patentable over Luo by virtue of its dependency from claim 21 as 
well as based on its own merits. In particular, claim 30 includes the feature of a "provider list 



22 



Customer No. 24498 Atty. Docket No. PU030084 

Appln. Serial No. 10/549,407 
Response to Final OA dtd 4/28/2009 

web page" absent from Luo. For the reasons discussed above in connection with claim 7, Luo 
does not teach or suggest this feature. 

Additionally, claim 30 includes the feature of an "ActiveX control/plug-in received from 
a local web server in response to receipt of a web request redirect message from an access point." 
Luo does not teach or suggest this feature. As shown in step 236, Fig. 2 of Luo, the Java applet 
is downloaded in response to the mobile host sending a fourth HTTP request over SSL. This 
fourth request is not in response to receipt of a web request redirect message from an access 
point. The fourth HTTP request in Luo is not a redirect message; and it is not from an access 
point but instead from a mobile host. For at least these reasons, reconsideration is respectfully 
requested. 

Claim 31 

Claim 31, directly or indirectly, depends on claim 24 and incorporates every feature 
thereof. Therefore, claim 31 is patentable over Luo by virtue of its dependency from claim 24 as 
well as based on its own merits. In particular, claim 31 includes the feature of "configuring the 
client terminal responsive to the receipt of selected provider information at the designated web 
server." For at least the reasons discussed in connection with claim 7, Luo does not teach or 
suggest this feature. For at least these reasons, reconsideration is respectfully requested. 

Applicant's counsel also will discuss what Applicants believe to be Graham v. Deere 
factors or differences between the present claims 1-31, as will be discussed further below, and 
what Luo describes. 

1. Luo, at Page 5, paragraph [0035], leads Applicants to believe that Luo practices a non- 
standard protocol by which protocol the "mobility access point" or MAP 102 communicates with 
a web authentication server 114 (Figure 1). Now referring to Luo FIG. 2, and paragraph [0035], 
at "202, the MAP sends an IAPP announcement message to the default gateway router of the 
WLAN and then sends a MOBILE STATE REQUEST message to the Web authentication server 
using the mobile host's (MH 106 of Figure 1) MAC address as the index. At this time the Web 
authentication server does not yet have a state record for the mobile host (106), so at 204 it 
creates a new state record for the mobile host. At 206, the Web authentication server inserts the 
mobile host's MAC address, sets the routing state to be 'limited,' assigns the MAP (102) as the 
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mobile's home agent, saves the state record in its database, and sends the state record back to the 
MAP in a MOBILE STATE RESPONSE message. The MAP knows that it is now the mobile 
host's home agent from the returned state record." This Luo MOBILE STATE REQUEST 
communication creates a strong inference of a non-standard protocol between the Web 
authentication server and the MAP. Moreover, the MH's MAC address is important (if not 
required) for authentication. 

2. Luo, at Page 5, paragraph [0045] underscores a further distinction between Luo's Java 
applet, relied upon by the Examiner, and Applicant's recited ActiveX control/plug-in or control. 
The Luo Java applet participates in listening for authentication challenge messages: "After the 
Java applet is downloaded at 238, it grants networking privileges so that it can listen to a specific 
UDP port for AUTHENTICATION CHALLENGE messages. The Java applet shares a high- 
entropy secret with the Web authentication server, which can be used to generate 
AUTHENTICATION RESPONSE messages." As supported by the present application and as 
will be described further below, an ActiveX control/plug-in, when received, "reconfigures the 
client terminal for authentication using appropriate parameters associated with a configuration 
arrangement selected by a user;" (see, for example, claim 1). This feature is not rendered 
obvious by Luo. 

3. Luo, at Page 5, paragraph [0046] requires the Java applet to be always open as it is 
needed to re-authenticate a user (client terminal or mobile host). "The mobile host can now use 
the assigned IP address during the entire session as long as it is under coverage of the WLAN. 
The user should always keep the small browser window open. The Java applet runs in this small 
browser and authenticates the user to the WLAN as the user moves from one MAP to another, " 
(Applicants' emphasis added). A client terminal of one embodiment is configured "in response 
to the client terminal access information received from the client terminal," for example, as 
recited in claims 1 and 5, which information, according to dependent claims 28 and 29, may be 
"provider selection" information. 

Claims 1 and 5 clarify that the recited "information" is "client access information" and 
"means for requesting . . ." has been added to claim 5. Claim 7 recites "issuing a provider list 
web page and a request from the designated web server to the client terminal for provider 
selection information to establish an authorized communication," which feature is not described 
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by Luo. Pending claims 10-18 correspond to the wording used in a (amended) replacement 
paragraph beginning at page 7, line 13 as follows: "In the course of the communication the web 
server 120 indicates to client terminal 140 n information corresponding to such parameters as 
transmission rates (claim 10), user account creation information (claim 11), authentication 
method selection information (claim 12), new account creation procedures (claim 13), access 
user terms as conditions of acceptance (claim 14), all typically required to establish an 
authorized communication. The client terminal 140 n user responds 365, accordingly 
communicating web server 120, access rate information (claim 15), web server user account 
creation information (claim 16), user access authentication method selection information (claim 
17), and user access terms and conditions of acceptance information (claim 18) required to 
establish an authorized communication," (Applicants' indication of claim numbers added). 
Claims 10-14 depend from claim 9 and claims 15-18 depend from respective claims 10-14. The 
Examiner's position may be that the recited establishment of an authorized communication of 
claims 10-20 may be suggested by Luo's statement: "new users can open accounts" at Luo 
paragraph [0018]. However, this statement is clearly not an enabling disclosure of claims 10-20. 

Claim 21 is directed to a "mobile terminal" (not described by Luo) at least as comprising: 
"means for forwarding a web access request via a packet traffic filter for filtering packet traffic 
as a web request redirect message; means for receiving a provider list web page; means for 
selecting a provider and means for forwarding selected provider information to a designated web 
server; means for receiving an ActiveX control/plug-in from the designated web server to 
reconfigure said mobile terminal; and means for reconfiguring said mobile terminal and 
establishing authorized communications." Luo does not describe any of these means. 

Claim 22 dependent on claim 1 reads: "creating a plurality of operational states including 
a progress state and a failure state, said packet traffic filter receiving wireless local area network 
failure state information via a redirected client message and moves a reconfiguration process to 
said local web server via a web request redirect message." Claim 23 reads similarly to claim 22, 
and claims 22 and 23 are supported by Zhang et al. paragraph [0020] - [0021] as amended. 
Claims 22 and 23 are not suggested or described by Luo. 

Independent claim 24 reads: "means for forwarding a web request redirect from said 
packet filter module to a designated web server for establishing authorized communications 
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following receipt of selected provider information at the designated web server and successful 
client terminal reconfiguration responsive to authentication." Claim 24, while supported, for 
example, by Zhang et al. FIG. 2 is not described by Luo. Claim 31 dependent on claim 24 
relates to an ActiveX control/plug-in not suggested or described by Luo's Java applet which, as 
described above, performs differently. 

Luo discusses a RADIUS server 110 in the BACKGROUND: "requires that every user 
have an account at a centralized authentication server, such as a Remote Authentication Dial In 
User Service (RADIUS) server;" (See Luo paragraph [0013]). Luo discusses a RADIUS server 
supporting ZCMN at paragraph [0020] and as being responsible for network-to-user 
authentication and for generating session-specific keys to encrypt air traffic at paragraph [0027]. 
"It does not [to] enforce user-to-network authentication" which is "handled by the Web 
authentication server;" (Applicants note an apparent typographical error). Consequently, it is 
respectfully submitted that Luo teaches away from the subject matter of claims 25-27. 

Claims 28-29 are directed, for example, at defining "information to establish client 
terminal access to the wireless network" of claims 1 and 5 as "provider selection information." 
"Provider selection information" as recited in context is not discussed in Luo. 

Claim 30 dependent on mobile terminal claim 21 is similar to new claim 31 and directed 
to the ActiveX control/plug-in not disclosed or suggested by Luo. 

The following are some advantages of claims 1-31: use of a standard protocol, the 
ActiveX/plug-in does not have to be open and listening and Applicants' activating a module "in 
response to client terminal access information received from the client terminal," among other 
advantages. 

At MPEP 707. (f), Examiners are encouraged to "state the reasons for his or her position 
in the record, preferably in the action following the assertion or argument relative to such 
advantages." Here, the Examiner is silent about the advantages of the present reconfiguration. 
The MPEP states: "The Examiner should never lose sight of the fact that in every case the 
applicant is entitled to a full and fair hearing, and that a clear issue between the applicant and the 
examiner should be developed, if possible, before appeal." 

The Examiner, having failed to make a prima facie case of anticipation of independent 
claims 1 and 5, let alone, independent claims 7, 21 and 24, Applicants respectfully request 
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withdrawal of the anticipation rejection of the independent claims. Moreover, Applicants 
respectfully request serious consideration of dependent claims 2-4, 6, 8-20, 22-23 and 25-31 as 
reciting allowable subject matter when considered in the context of the claims on which they 
depend. It is respectfully submitted that the independent claims 1, 5, 7, 21 and 24 are in 
condition for allowance and that further features recited in dependent claims have not been 
shown to be anticipated by Luo. The "anticipation" rejection of claims 1-31 should be 
withdrawn and a new Office Action should issue. 

Applicants respectfully request reconsideration of the anticipation rejection of claims 1- 
31 and look forward to prompt allowance of the application. Our Washington DC counsel, 
Thomas Jackson, Registration No. 29808, has been authorized to request a telephonic or personal 
interview to further discuss allowability of the present application and pending claims 1-31. 
Should the Examiner have any questions on this request, the Examiner is urged to contact the 
undersigned attorney of record at the telephone number and address given. 
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No additional fees are believed due. The Office is authorized to charge any additional 

fees it believes are due to our deposit account 07-0832. In the event any additional fee or a 

refund is due, the Office is authorized to debit/credit our deposit account accordingly. 

Respectfully submitted, 
Junbiao Zhang, et al. 



By: /Catherine A. Ferguson/. 

Catherine A. Ferguson, 
Attorney for Applicant 
Reg. No. 40877 

Date: June 23, 2009 

Patent Operations 
Thomson Licensing LLC 
P. O. Box 5312 

Princeton, New Jersey 08543-5312 
Telephone: (609) 734-6440 
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